Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-113.txt

Text File | 1994-12-08 | 47.4 KB | 1,253 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 14 Jun 92       Volume 1 : Issue 113

Today's Topics:

    Fortran callable graphing library wanted for Mac
    Delete menu items?
    Where can I find Oberon?
    Format of a mac Disk?
    Getting a Files full Pathname
    C (C++) Prettyprinter
    MacTutor version 2.0
    New Developer Tool from Apple & AT&T?
    HELP! *BIGGER* Handle woes


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

Subject: Fortran callable graphing library wanted for Mac
From: [e-mail] (Martin Visser)
Date: 12 May 92 17:01:01 +1000
Organization: BHP Steel - Slab and Plate Products Division - Port Kembla AUSTRALIA

G'day,

Our Industrial Engineering group are in the business of analysing our plant
processes and systems, interpreting information for management. Having recently
acquired some Quadra's they are setting up a development environment. The
application requires custom data analysis; to this end Fortran is the preferred
tool.
We currently use Absoft's Mac Fortran /020 soon to upped to Mac Fortran II. What
we want is good quality package that is Fortran-callable that will provide good
graphical presentation of data. This library should be able to all the
formatting, axis annotation, point plotting etc. Currently only 2-D line graphs
and histograms are necessary, but 3-D styles, contours etc. are likely to be a
future requirement. It must be able to be linked into the fortran program into a
stand-alone package. Also previewing on the screen, LaserWriter and HP ColorInkjet output is required.

We require information on package availabilit, performance, etc. fairly urgently
. I will summarise to the net on results.

Thanks in advance, Martin.


- --
   /\/\     :  Martin Visser - Electrical / Software Engineer
  / / /\    :  Engineering Technology Department
 / / /  \   :  BHP Steel - Slab and Plate Products Division
/ / / /\ \  :  P.O. Box 1854 Wollongong NSW 2500 AUSTRALIA
\ \/ / / /  :  Phone    [phone]
 \  / / /   :  E-mail   [e-mail]
  \/\/\/

---------------------------

From: [e-mail] (John Hardin)
Subject: Delete menu items?
Date: 11 May 92 18:11:49 GMT
Organization: MCC CAD Program, Austin, Texas

I'm dynamically computing the items that need to be displayed in a
popup menu.  When the list needs to be changed, I need to delete the
existing list before creating the new one.  I've been using AppendMenu
to add items, but don't see any analog for deleting menu items.  Am I
missing something?  Perhaps I need to throw the entire menu away and
recreate it?  (This seems a little heavy-handed.)

Thanks in advance for any help.

- -jwh

- --
John W. Hardin            phone:  [phone]
MCC                email:  [e-mail]
3500 W. Balcones Center Dr  fax:    [phone]
Austin, TX  78759-6509        uucp:   ...!cs.utexas.edu!milano!cadillac!hardin

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 12 May 92 23:53:18 GMT
Organization: The World Public Access UNIX, Brookline, MA

To delete an item from a menu you should use:

DelMenuItem(theMenu, itemID);

- --
- -- joe zobkiw                             Internet: [e-mail]
- --                                             AOL: AFL Zobkiw
- -- mac.synthesis.MIDI.THINK C.OOP.asm          CI$: 70712,515
- -- communications.networks.cool tunes...

---------------------------

Subject: Where can I find Oberon?
From: [e-mail]
Date: 12 May 92 12:44:28 EST
Organization: Wright State University


    What is the FTP address where I can find Oberon?

    thanks in advance.


---------------------------

Subject: Format of a mac Disk?
From: [e-mail]
Date: 13 May 92 22:59:37 GMT
Organization: Wellington City Council, Wellington, NZ

I am trying to get some detailed information on the format of a macintosh disk
(ie sector gap length, steprate of the drives, etc, NOT the layout info, (ie
data layout, which is in inside mac.)

Please could someone either mail me with the info, or post it here, or tell me
whereabouts I can get hold of it. (preferably not book refs, as they can be
difficult to get hold of).

I hope I am asking in the right group, if not tell me where I should ask.

Thanks in advance...

---------------------------

From: [e-mail] (Kristopher L Tyra -- The Sapphire Group)
Subject: Getting a Files full Pathname
Organization: The Sapphire Group
Date: Fri, 1 May 1992 03:37:52 GMT

This is probably a stupid question but I can't seem to figure it out.
I need the full pathname of a file returned by lets say SFGetFile.
SFGetFile will give me the file name and the volume reference but i need
the ':' separated full pathname of the file selected.

I am working with System 7 under A/UX and I need to convert the file name
to an A/UX file name(changing ':' to '/').

Thanks in advance.

                                ________________________________
                                Kristopher L. Tyra
                                The Sapphire Group
                                [phone]
                                [e-mail]
                                Consultants - A/UX, OSF, AIX/ESA,
                                              Sun, X-Windows, MacOS


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 1 May 92 18:50:27 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Kristopher L Tyra -- The Sapphire Group) writes:
>
> This is probably a stupid question but I can't seem to figure it out.
> I need the full pathname of a file returned by lets say SFGetFile.
> SFGetFile will give me the file name and the volume reference but i need
> the ':' separated full pathname of the file selected.
>
> I am working with System 7 under A/UX and I need to convert the file name
> to an A/UX file name(changing ':' to '/').

I don't want to be rude, but I do want to put this firmly: No, you _don't_ need
"the full pathname of a file returned by lets say SFGetFile." There are many
reasons why getting a full pathname is bad, including:

- - it makes your program inefficient copying around that string.
- - it's possible to generate a string longer than the File Manager can handle.
- - it's inefficient for the File Manager, because it will just have to reconvert
the pathname back into the vRefNum/dirID/filename that it handed you in the
first place.
- - there are compatibility issues like with A/UX.
- - there are issues with trying to save the pathname to a file.

If you think you need to get a full pathname, post your reason here; it's likely
that we can show you a better way. Additionally, take a look at Technote #238.
It shows how to generate a full pathname, and also tells you why you shouldn't
do it.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Joe Francis)
Date: 1 May 92 20:36:08 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Keith Rollin) writes:

> I don't want to be rude, but I do want to put this firmly: No, you _don't_ need
> "the full pathname of a file returned by lets say SFGetFile." There are many
> reasons why getting a full pathname is bad, including:

Then don't be rude!  :-)  Yes, you _may_ need the full pathname.

There is an excellent reason why a program would need to get the full
pathname: to display (or print) it for the user!  Nowhere did
Kristopher Tyra say that it would be used as input for the hapless File
Manager.

+++++++++++++++++++++++++++

From: [e-mail] (Jay H. Lieske)
Date: 1 May 92 21:59:25 GMT
Organization: Jet Propulsion Laboratory

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>
>I don't want to be rude, but I do want to put this firmly: No, you _don't_
need
>"the full pathname of a file returned by lets say SFGetFile."
>[..]
>
>If you think you need to get a full pathname, post your reason here; it's
likely
>that we can show you a better way.
>
>--
>Keith Rollin
>Phantom Programmer
>Taligent, Inc.
>
>
    Sounds a bit judgmental to me, Keith.  Hope your new book isn't that way.  One
reason I extract full path names is for archival purposes.  I execute programs
and let the user select the input file.  Then in the output file I give the
full path name to the input file.  If I didn't do that I wouldn't know what
data file was processed etc.

Jay H. Lieske                                            [e-mail]
Jet Propulsion Laboratory
Pasadena, CA 91109

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 2 May 92 21:44:31 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Jay
H. Lieske) writes:
>
> In article <[e-mail]> [e-mail] (Keith Rollin) writes:
> >
> >I don't want to be rude, but I do want to put this firmly: No, you _don't
> _need
> >"the full pathname of a file returned by lets say SFGetFile."
> >[..]
> >
> >If you think you need to get a full pathname, post your reason here; it's
> likely
> >that we can show you a better way.
> >
> >
>     Sounds a bit judgmental to me, Keith.  Hope your new book isn't that way.
One
> reason I extract full path names is for archival purposes.  I execute programs
> and let the user select the input file.  Then in the output file I give the
> full path name to the input file.  If I didn't do that I wouldn't know what
> data file was processed etc.

Perhaps it is judgemental. There was no way for me to know what your purpose
was, and there's no way I can think of every reason why someone would want to
generate a full pathname and categorically say "You're wrong." However, years of
professional experience in supporting developers have shown me that the majority
of people asking this question are asking it for the wrong reason. That's why I
said it was "likely" we can show you a better way.

I'm still not sure if you need to generate a full pathname for your task. If you
need to create output for human eyes, then generating a full pathname is OK. For
instance, MPW puts full pathnames in window titles and its Window menu, which is
OK. However, if you need to generate output for a computer's eyes, then you
should take a different approach. Instead, save the volume name, directory ID,
and file name. When running under System 7.0, save an alias to the file.

My philosophy on tech support is to tell people the dangers of what they want to
do, and then tell them how to do it. That's why I pointed you toward Technote
#238. I leave the final determination up to you.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Kristopher L Tyra -- The Sapphire Group)
Date: 4 May 92 13:18:18 GMT
Organization: The Sapphire Group

In article <[e-mail]> [e-mail] (Joe Francis) writes:
>In article <[e-mail]>
>[e-mail] (Keith Rollin) writes:
>
>> I don't want to be rude, but I do want to put this firmly: No, you _don't_ need
>> "the full pathname of a file returned by lets say SFGetFile." There are many
>> reasons why getting a full pathname is bad, including:
>
>Then don't be rude!  :-)  Yes, you _may_ need the full pathname.
>
>There is an excellent reason why a program would need to get the full
>pathname: to display (or print) it for the user!  Nowhere did
>Kristopher Tyra say that it would be used as input for the hapless File
>Manager.

Thank you.  I couldn't have said it better.  The full path is being used for
an A/UX backup/restore software package.  It does not use the MacOS File
manager but rather the A/UX Filesystem.  SFGetFile does not actually change
the A/UX process current working directory; therefore, a file selected by
SFGetFile would not have been stat'd correctly by the A/UX filesystem.
And yes I must use A/UX to get permission information NOT MacOS.

Sorry, that the question was so simple.  I didn't look at SC18 as it was
pointed out to me.  I am Unix developer not MacOS so the mac file system
was a bit strange to me.  Thanks for those who responded and especially to
Mats Wichmann who sent me the code - I only had to change the memory
management and the directory seperator at it worked great.

To keith@taligent: I had high hopes for the taligent project.  I believe that
those hopes have been dashed.  Nugh said.

                                ________________________________
                                Kristopher L. Tyra
                                The Sapphire Group
                                [phone]
                                [e-mail]
                                Consultants - A/UX, OSF, AIX/ESA,
                                              Sun, X-Windows, MacOS

+++++++++++++++++++++++++++

From: [e-mail] (Kristopher L Tyra -- The Sapphire Group)
Date: 4 May 92 18:29:11 GMT
Organization: The Sapphire Group


Appoligies to Charles Cranston:  I reported that Mats Wichmann sent me
the correct stuff but it was Charles.  Thanks again.

                                ________________________________
                                Kristopher L. Tyra
                                The Sapphire Group
                                [phone]
                                [e-mail]
                                Consultants - A/UX, OSF, AIX/ESA,
                                              Sun, X-Windows, MacOS

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 4 May 92 18:44:29 GMT
Organization: Kalamazoo College

[e-mail] (Kristopher L Tyra -- The Sapphire Group) writes:
>[e-mail] (Joe Francis) writes:
>>[e-mail] (Keith Rollin) writes:
>>
>>> I don't want to be rude, but I do want to put this firmly:
>>> No, you _don't_ need
>>> "the full pathname of a file returned by lets say SFGetFile."
>>
>>Then don't be rude!  :-)  Yes, you _may_ need the full pathname.
>
>Thank you.  I couldn't have said it better.  The full path is being used for
>an A/UX backup/restore software package.
>And yes I must use A/UX to get permission information NOT MacOS.

Excuse my ignorance with A/UX (never used it), but the 7.0 File Manager
"introduces a number of special-purpose functions that you can use
to...manipulate access-control privileges in foreign file systems."
Now that A/UX 3.0 is out, can you use the MacOS to get Unix's permission
information?  Read up on PBGetForeignPrivs().

Can you use the Alias Manager to keep track of these files?  It will do
a very good job, and with very little coding.  Read the description of
the algorithm used for the "fast search"--it sounds like it's right up
your alley.  If you _can_ use the Toolbox's built-in file tracking,
instead of clutching to a full path and hoping the user never changes
folders' names, you should.

>To keith@taligent: I had high hopes for the taligent project.  I believe that
>those hopes have been dashed.  Nugh said.

Speaking of _rude_!

Keith, I believe I speak for (nearly) everyone on csmp when I say:  we
appreciate the time you take to answer questions in this newsgroup, and
we hope Kristopher's comments don't discourage you from continuing to
do so.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Son, I am able," she said, "though you scare me." "Watch," said I,
 "beloved," I said, "watch me scare you though." Said she, "able am I, son."

+++++++++++++++++++++++++++

From: [e-mail] (Kristopher L Tyra -- The Sapphire Group)
Date: 4 May 92 21:05:39 GMT
Organization: The Sapphire Group

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:

>
>Excuse my ignorance with A/UX (never used it), but the 7.0 File Manager
>"introduces a number of special-purpose functions that you can use
>to...manipulate access-control privileges in foreign file systems."
>Now that A/UX 3.0 is out, can you use the MacOS to get Unix's permission
>information?  Read up on PBGetForeignPrivs().
>
>Can you use the Alias Manager to keep track of these files?  It will do
>a very good job, and with very little coding.  Read the description of
>the algorithm used for the "fast search"--it sounds like it's right up
>your alley.  If you _can_ use the Toolbox's built-in file tracking,
>instead of clutching to a full path and hoping the user never changes
>folders' names, you should.

Interesting, I will look into this for some future work with mixing
A/UX and Mac.  Thanks for the info.  I'm afraid that it won't help much with
the current project.  The application is a MacOS UI for an
already existing Unix application using an Object Class that requires
Unix filenames and filesystems.  It is not designed to run under
standalone MacOS only A/UX.  Clients wishes not mine.  Thanks again for
the info.

>
>>To keith@taligent: I had high hopes for the taligent project.  I believe that
>>those hopes have been dashed.  Nugh said.
>
>Speaking of _rude_!
>
>Keith, I believe I speak for (nearly) everyone on csmp when I say:  we
>appreciate the time you take to answer questions in this newsgroup, and
>we hope Kristopher's comments don't discourage you from continuing to
>do so.
>--
As a _hopefully_ last comment on this situation, my appoligies to Kieth are
in order - that was a bit of a harsh statement.  I was trying to drive at
a point of _assumptions_.  By assuming that what Keith says represents what
Taligent is or isn't is as _wrong_ as to assume that a question asked on the
net is made by someone who doesn't know anything about what they are
asking.

With I believe the success of A/UX, this group will find more questions
of mixed environments asked.  I hope that Keith and others of this group
will continue to answer these questions with some understanding.  My
sincere appoligies to Kieth and anyone who may have been insulted by my
rash statement.

            ______________________________________
            Kristopher L. Tyra
            [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Xavier Mora)
Date: 4 May 92 23:31:23 GMT
Organization: SRI International



In article  Keith Rollin, [e-mail] writes:


>If you think you need to get a full pathname, post your reason here;
it's likely
>that we can show you a better way. Additionally, take a look at Technote
#238.
>It shows how to generate a full pathname, and also tells you why you
shouldn't
>do it.

What if you are writing a backup application? Don't you need to know the
full pathname to be able to restore an erased volume? Or does just
knowing the
DirId magically recreate the folder hiearchy?
- --

- ---------------------------------------------------------------------
- ------
|Matthew Mora
[e-mail] |
|SRI International
[e-mail] |

- ---------------------------------------------------------------------
- ------

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Xavier Mora)
Date: 4 May 92 23:50:40 GMT
Organization: SRI International


In article  Jamie R. McCarthy, [e-mail] writes:

>[e-mail] (Kristopher L Tyra -- The Sapphire Group) writes:
>
>>To keith@taligent: I had high hopes for the taligent project.  I
believe that
>>those hopes have been dashed.  Nugh said.
>
>Speaking of _rude_!
>
>Keith, I believe I speak for (nearly) everyone on csmp when I say:  we
>appreciate the time you take to answer questions in this newsgroup, and
>we hope Kristopher's comments don't discourage you from continuing to
>do so.

Wow! What is this? Bash on Keith week? First it was Tim, now its
Kristopher.
Keith, I would like to ditto the remarks of Jamie.

Oh by the way, didn't you just write a book? Please tell me ALL about it.
(That should eat up some more of Tim's precious bandwidth) :-)


- --

- ---------------------------------------------------------------------
- ------
|Matthew Mora
[e-mail] |
|SRI International
[e-mail] |
|"Selling skin, selling god, the numbers look the same on their credit
card."|
|                                        "Queensryche - Operation
Mindcrime" |

- ---------------------------------------------------------------------
- ------

+++++++++++++++++++++++++++

From: Christopher Tate <[e-mail]>
Date: Monday, 4 May 1992 23:57:02 EDT
Organization: Penn State University

In article <[e-mail]>, [e-mail] (Matthew Xavier Mora) says:
>
>What if you are writing a backup application? Don't you need to know the
>full pathname to be able to restore an erased volume? Or does just
>knowing the
>DirId magically recreate the folder hiearchy?

I don't imagine the DirID gives you any heirarchy information, but you
could simply store the name of each file's parent folder.  Or, your could
structure your backup image in such a way that you know how to descend/
ascend through the directory structure as you rebuild from the image.
This has the added advantage of requiring very little additional info
beyond each file's name and contents.

[For example, if you topsort your hierarchy in some way (depth-before-
breadth, for example) you can reconstruct the hierarchy directly from
the ordering of files/folders in the sorted list, given only the valences
of each folder.]

- -------
Christopher Tate     | Cryptogram #24:
[e-mail] |
[e-mail]  | LPL UTE ZCTX FYGF XYDC UTE SDGSSGCRD FYD BDFFDSO
- ---------------------| PC 'RDTSRD YDSNDSF XGBZDS NEOY' UTE RDF 'YERD
Send me the answer!  | NDSODSZ SDNDB XGSFYTR?'

+++++++++++++++++++++++++++

From: [e-mail] (Andrew E Page)
Date: 13 May 92 15:14:41 GMT
Organization: The World Public Access UNIX, Brookline, MA

/*
* The Follwing will generate full pathname for you
* let me know if you have problems with this.  excuse
* the netnews unfriendly formatting.
*/


#include <Types.h>
#include <Files.h>
#include <Memory.h>
#include <ToolUtils.h>

/*
91/07/11    FullPathname by Andrew E. Page.  Function returns a handle to a string
ode resource */

    /*
    * Initialize the PB fields
    */

    F.hFileInfo.ioNamePtr = fName ;    /* pascal string for the name, and also subsequent storage on calls */
    F.hFileInfo.ioVRefNum = vRef ;    /* volume reference (Gotten from SFGetFile perhaps */
    F.hFileInfo.ioCompletion = 0L ;    /* initialize this field or get a Serious BOMB */
    F.hFileInfo.ioFDirIndex = 0 ;        /* for the first call only.  Get CatInfo based on ioNamePtr and ioVRefNum */
    F.hFileInfo.ioDirID = 0 ;                /* clear this field to ensure PBGetCatInfo will not use it */

    for( ;; )
        {
        err = PBGetCatInfo(&F,0) ;
        if( err )
            break ;

        /*
        * Insert the directory level into the front of the string
        */

        Munger(theString, 0, 0L, 0, &fName[1], fName[0]) ;

        /*
        * Insert a colon in front of the Directory Entry
        */

        Munger(theString, 0, 0L, 0, &colon, 1) ;

        F.dirInfo.ioDrDirID = F.dirInfo.ioDrParID ; /* get the ioDrDirID of the PARENT directory (the next level up) */
        F.hFileInfo.ioFDirIndex = -1 ;    /* for all subsequent calls.  GetCatInfo based on ioDrDirID */
        }

    /*
    * The last entry will be the Volume name which should not have a colon in front of it
    */

    Munger(theString, 0, 0L, 1, fName, 0) ;

    return theString ;

} /* end of FullPathName */


- --
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

---------------------------

From: [e-mail] (David Hull)
Subject: C (C++) Prettyprinter
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 4 May 1992 21:47:29 GMT

OK, what do YOU use to print out YOUR C code?

I've written some C++ code that I need to turn in to my advisor in a
few days and I think I would earn extra brownie points if it were
formatted really nicely, with bold keywords, italicized comments, etc.

I've tried PrettyC 1.51, but it keeps crashing on me.  If I could
get it to work it would be almost perfect.  Is there a later version?

- -David Hull

+++++++++++++++++++++++++++

From: [e-mail] (HP48SX Archive Maintainer)
Organization: Washington University in Saint Louis, Missouri USA
Date: Mon, 4 May 1992 23:17:43 GMT

[e-mail] (David Hull) writes:

>OK, what do YOU use to print out YOUR C code?

>I've written some C++ code that I need to turn in to my advisor in a
>few days and I think I would earn extra brownie points if it were
>formatted really nicely, with bold keywords, italicized comments, etc.

>I've tried PrettyC 1.51, but it keeps crashing on me.  If I could
>get it to work it would be almost perfect.  Is there a later version?

>-David Hull

There are some C macros for your favourite word processor (read Nisus).
I am not sure if they are on the Nisus site, or if you have to get them
from [e-mail]   They do quite a nice job.

The ultimate solution would still be to write code so good that the
layout doesn't matter :-)
- --
Povl H. Pedersen             [e-mail]
HP48sx archive maintainer

All Opinions (C) Copyright the Integalactic Thought Association

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 7 May 92 19:30:38 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail]
(David Hull) writes:
>
> OK, what do YOU use to print out YOUR C code?
>
> I've written some C++ code that I need to turn in to my advisor in a
> few days and I think I would earn extra brownie points if it were
> formatted really nicely, with bold keywords, italicized comments, etc.
>
> I've tried PrettyC 1.51, but it keeps crashing on me.  If I could
> get it to work it would be almost perfect.  Is there a later version?

Pretty C nearly works with C++, it does not like Quadras (place the application
as part of a possible compability CDEV listing), it does not like parsing
function prototypes with references ( foo(var&)), it is cranky about too
many keywords added to its list. Otherwise I could get it working somehow
with pure C++ code.

After printing out C++ code with Pretty C for two days I realized that it
looked far too 'flashy', and bold/italics does not always make source
code look good. Actually I use SaveATree 1.5 nowadays with two-column
formatting and Palatino-6pt as a font, that's nice and simple.

As for good formatters, when I was a UNIX hacker I used indent a lot,
printed out whole BSD source code listings in postscript using it. That
tool was really nice, has anyone ported it to MPW?

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Thomas R. Kimpton)
Date: 12 May 92 22:41:18 GMT
Organization: Digital Technology, International


I haven't done much printing of program listings since I went to
work here, they have 21" monitors for the Mac's allowing two full
pages side by side.  But when I was working for a unix company
we used a program called "vgrind".  Just looking on our Sun I see
that it is available there and supports C and Pascal (among others).
The man page seems to indicate that it is "customizable" in the
form of definition files, so you could probably make it work with
C++.  I remember it printing files out in a really nice manner, and
even being able to rotate the pages and put two pages on a single
sheet of paper.

Tom.

- --
- ---
Tom Kimpton                            [e-mail]
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

---------------------------

From: [e-mail] (R. Withers Morgan)
Subject: MacTutor version 2.0
Date: 8 May 92 13:02:34 GMT
Organization: Computer Science Dept, University of Tennesee, Knoxville

I just picked up the April/May issue (vol 8, no 1) of MacTutor 2.0

A company by the name of XPlain has purchased the rights to the
magazine, and has just released their first issue.  The last issue
was (I think) the Nov '92.

Subscribers should be receiving their copies, with adjustments to
their expiration dates to reflect the missing issues.

MacTutor 2.0 is, of course, new and improved (aren't they all), but
it still looks much the same to me.  The layout is cleaner, and there's
some use of color, but still the same basic content.  It sounds like
(from reading the editorial) that these guys have some big plans for
MacTutor.

So now you know...

Unfortunately, I forgot to bring the phone number to work with me.
If someone else has it, please post, otherwise I'll do it myself
tonight.

Withers

+++++++++++++++++++++++++++

From: /home/imperial/mes (Mark Stockwell)
Organization: Shell Development Co., Bellaire Research Center, Houston TX
Date: Sun, 10 May 92 19:28:39 GMT

MacTutor can be reached at [phone]. According to the first issue which
is now on newstands in Houston, at least, they can also be reached on the
Internet at: [e-mail].

Mark Stockwell




+++++++++++++++++++++++++++

From: [e-mail] (Joe Block)
Date: 12 May 92 13:50:19 GMT
Organization: Gene Police - Interstellar Enforcement Division, Sol III Office

Does anyone know the details of how Xplain acquired MacTutor?
- --
Joe Block ([e-mail])
"They that can give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety." - Benjamin Franklin
                                        Historical Review of Pennsylvania, 1759

---------------------------

From: [e-mail] (Chrome Cboy)
Subject: New Developer Tool from Apple & AT&T?
Organization: University of Maryland at College Park
Date: Wed, 6 May 1992 16:01:11 GMT

Howdy all!
    I was reading through the Washington Post yesterday and ran across this
in the Business Digest section:

"Apple will use technology developed by AT&T's Bell Labs that could radically
speed up a time-consuming step in developing computer programs, the companies
said."

Real informative, eh? :-) Anyway, I haven't seen a press release from Apple, so
I was wondering if anyone out there could enlighten me as to what the
technology is. Gotta try and eliminate those "time-consuming step[s]," don'cha
know? TIA...
- --
"Seeing much, suffering much            -Blake Sobiloff ([e-mail])
and studying much, are the               Human-Computer Interaction Lab
three pillars of learning."              Department of Psychology
         -Disraeli                       University of Maryland

+++++++++++++++++++++++++++

From: [e-mail] (Mark Lanett)
Date: 6 May 92 17:24:09 GMT
Organization: University of Illinois at Urbana

[e-mail] (Chrome Cboy) writes:

>Howdy all!
>    I was reading through the Washington Post yesterday and ran across this
>in the Business Digest section:

>"Apple will use technology developed by AT&T's Bell Labs that could radically
>speed up a time-consuming step in developing computer programs, the companies
>said."

You expecting them to announce a new incremental compiler/dynamic linker?
Given typical newspaper computer illiteracy, I wouldn't be surprised if they
are just referring to CFront (which has sped up my time-consuming steps a
whole lot, I tell you - NOT).

>Real informative, eh? :-) Anyway, I haven't seen a press release from Apple, so
>I was wondering if anyone out there could enlighten me as to what the
>technology is. Gotta try and eliminate those "time-consuming step[s]," don'cha
>know? TIA...
- --
Mark Lanett, NCSA Software Development - [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Chrome Cboy)
Organization: University of Maryland at College Park
Date: Wed, 6 May 1992 23:16:46 GMT

In article <mlanett.705173049@void> [e-mail] (Mark Lanett) writes:
>[e-mail] (Chrome Cboy) writes:
>>Howdy all!
>>    I was reading through the Washington Post yesterday and ran across this
>>in the Business Digest section:
>>"Apple will use technology developed by AT&T's Bell Labs that could radically
>>speed up a time-consuming step in developing computer programs, the companies
>>said."
>You expecting them to announce a new incremental compiler/dynamic linker?
>Given typical newspaper computer illiteracy, I wouldn't be surprised if they
>are just referring to CFront (which has sped up my time-consuming steps a
>whole lot, I tell you - NOT).

Well, it wouldn't have been to hard to say "...radically speed up compiling, a
time-consuming step...," but your point about computer illiteracy is well-
taken. <sigh> :-)
- --
"Seeing much, suffering much            -Blake Sobiloff ([e-mail])
and studying much, are the               Human-Computer Interaction Lab
three pillars of learning."              Department of Psychology
         -Disraeli                       University of Maryland

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 12 May 92 17:47:55 GMT
Organization: Taligent, Inc.

In article <mlanett.705173049@void>, [e-mail] (Mark Lanett)
wrote:
>
> You expecting them to announce a new incremental compiler/dynamic linker?
> Given typical newspaper computer illiteracy, I wouldn't be surprised if they
> are just referring to CFront (which has sped up my time-consuming steps a

>From what I've read, the announcement refers to some way of converting object
code from one processor to another.  (In this case 68000 binaries to PowerPC
binaries.)

Larry

---------------------------

From: [e-mail] (Laurence Arthur Pittenger)
Subject: HELP! *BIGGER* Handle woes
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: Mon, 11 May 1992 02:55:13 GMT


Thanks to folks for their suggestions on how to make sure a
bomb-generating value is not passed to a handle routine.

Unfortunately, the situation I have is a little more tricky.  In
windows I own, I set the refCon to a Handle to one of my data
structures.  When an event comes through, I find out if it pertains to
one of my windows by seeing if the (Handle) casted refCon of the
window points to a block of the correct size.

Thus when, for example, my application's windows aren't being
displayed (or for any other reason I get a window which isn't mine),
the refCon is an unpredictable value.

So what I need is some way of asking "Is this a valid Handle?" before
I try to use it as such (and thus potentially bomb out).

Any thoughts anyone?

Hmmmmm.
LP
- --

Laurence A. Pittenger
CSNET  : [e-mail]
BITNET : pitlaua@yalevm ,  pittenger-laurence@yalecs

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Mon, 11 May 1992 04:34:44 GMT

(Why the "usa" distribution?)

[e-mail] (Laurence Arthur Pittenger) writes:
>
>Unfortunately, the situation I have is a little more tricky.  In
>windows I own, I set the refCon to a Handle to one of my data
>structures.  When an event comes through, I find out if it pertains to
>one of my windows by seeing if the (Handle) casted refCon of the
>window points to a block of the correct size.
>
>Thus when, for example, my application's windows aren't being
>displayed (or for any other reason I get a window which isn't mine),
>the refCon is an unpredictable value.

This isn't a real great idea, for a number of reasons.  The first is the
problem you've been having.  The second is, what if the app that owns
the window set its refCon to a handle that just happens to be the same
size as the one you would have set?

If you want to keep track of which windows are yours, the best and
surest way to do it is...keep track of your windows!  Make a linked list
of the WindowPtr's for each window you allocate.  (You can be sure they
won't move around, because they have to be nonrelocateable or they won't
work.)  You can still keep storing that handle in that refCon, as long
as you check to be sure the WindowPtr's in your linked list before you
try using it...
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Ceci n'est pas une .signature.

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 11 May 92 17:01:45 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>(Why the "usa" distribution?)

Why not just change it?

>[e-mail] (Laurence Arthur Pittenger) writes:
>>
>>Unfortunately, the situation I have is a little more tricky.  In
>>windows I own, I set the refCon to a Handle to one of my data
>>structures.  When an event comes through, I find out if it pertains to
>>one of my windows by seeing if the (Handle) casted refCon of the
>>window points to a block of the correct size.
>>
>>Thus when, for example, my application's windows aren't being
>>displayed (or for any other reason I get a window which isn't mine),
>>the refCon is an unpredictable value.
>
>This isn't a real great idea, for a number of reasons.  The first is the
>problem you've been having.  The second is, what if the app that owns
>the window set its refCon to a handle that just happens to be the same
>size as the one you would have set?
>
>If you want to keep track of which windows are yours, the best and
>surest way to do it is...keep track of your windows!  Make a linked list
>of the WindowPtr's for each window you allocate.  (You can be sure they
>won't move around, because they have to be nonrelocateable or they won't
>work.)  You can still keep storing that handle in that refCon, as long
>as you check to be sure the WindowPtr's in your linked list before you
>try using it...

Here's the way I usually keep track of which windows my program owns:

1) Define a new record data type which is a superset of DialogRecord. For
example:

    TYPE    MyWindowRecord = RECORD
            window:DialogRecord;
            data:Handle;
        END;

2) When the window is created, pass a memory block of SIZEOF(MyWindowRecord)
bytes, not SIZEOF(DialogRecord) bytes, and specify only a 4-byte ID value for
the refCon.  It makes sense to use the application signature for this value.

Under these circumstances, all one needs to do to determine ownership of a
window is to check if the refCon matches the signature.  If it does, you know
that you have an extended window record, and can access the extra field
containing the data handle.  You don't have to worry about bus errors when
testing the refCon, because it's a straight 4-byte quantity,not an OS
structure.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Tue, 12 May 1992 11:44:17 GMT

In article <[e-mail]> [e-mail] (Laurence Arthur Pittenger) writes:
>Thanks to folks for their suggestions on how to make sure a
>bomb-generating value is not passed to a handle routine.
>
>Unfortunately, the situation I have is a little more tricky.  In
>windows I own, I set the refCon to a Handle to one of my data
>structures.  When an event comes through, I find out if it pertains to
>one of my windows by seeing if the (Handle) casted refCon of the
>window points to a block of the correct size.
>
>Thus when, for example, my application's windows aren't being
>displayed (or for any other reason I get a window which isn't mine),
>the refCon is an unpredictable value.
>
>So what I need is some way of asking "Is this a valid Handle?" before
>I try to use it as such (and thus potentially bomb out).

John C. in another posting  has already pointed out a clean solution.
Nontheless, here is my attempt at providing a dirty solution to the original
question. There are a few weaknesses in this code, but I doubt you will
get it to produce an address error for any normal memory setup (One exception I
can think of are macs with a memory upgrade that makes the ROM appear in the
middle of the application heap).

/* Heuristic to determine whether a given address is a Handle            */
/* Based on the articles of Lloyd Lim and Matthew T Russotto in the UMPG */
/* This code may be redistributed without any restrictions               */

Boolean RealHandle(void * addr)
{
   THz   sysZone;
   THz   applZone;
   THz   heapZone;

   addr  =  StripAddress(addr);
   if (addr && !((long) addr & 1))  {
      sysZone  =  SystemZone();
      applZone =  ApplicZone();
      if (addr >= (Ptr) &sysZone->heapData   &&
          addr <  (Ptr) sysZone->bkLim          ||
          addr >= (Ptr) &applZone->heapData  &&
          addr <  (Ptr) applZone->bkLim
         )
         if (*(long *)addr && !(*(long *)addr & 1)) {
            heapZone =  HandleZone(addr);
            if (!MemError())
               if (heapZone == sysZone || heapZone == applZone)
                  return true;
         }
   }

   return false;
}

Matthias

- -----
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

+++++++++++++++++++++++++++

From: [e-mail] (Reid Ellis)
Organization: Alias Research, Inc., Toronto ON Canada
Date: Tue, 12 May 1992 14:22:09 GMT

Jamie R McCarthy <[e-mail]> writes:
|If you want to keep track of which windows are yours, the best and
|surest way to do it is...keep track of your windows!

Or, use the windowKind field to identify it as (a) an application
window, and hopefully (b) your window.  I quote from IM 1, p 276:

>WindowKind identifies the window class.  If negative, it means the
>window is a system window. [...] It may also be one of the following
>predefined constants:
>
>    CONST dialogKind    = 2;     {dialog or alert window}
>    CONST userKind      = 8;    {window created directly by the application}
>
>[...] UserKind represents a window created directly by application
>calls to the Window Manager; for such windows the application can in
>fact set the window class to any value greater than 8 if desired.
                              ^^^^^^^^^^^^^^^^^^^^^^^^
And that's the key.  You can pick some [hopefully unique] 16-bit value
greater than 8 and, if you find a window with this value in its
windowKind field, AND its refCon is a handle to data of the correct
size, then chances are really really good that it's one of yours.

Actually, unless you are writing an INIT or something, [i.e. if you
are writing a normal application] any window with a windowKind >= 8
MUST be one of your windows, so you can dispense with the check for a
handle to a valid size.  You just have to be careful that ALL CREATED
WINDOWS have a refCon that is either zero [NULL] or a valid handle.

Reid
- --
Reid Ellis
[e-mail]        ||           [e-mail]
[e-mail] ||  [phone] [work]

+++++++++++++++++++++++++++

From: [e-mail] (marco piovanelli)
Organization: Computer Science Dep. - Milan University
Date: Wed, 13 May 1992 13:00:10 GMT

[e-mail] (Reid Ellis) writes:

>Jamie R McCarthy <[e-mail]> writes:
>>If you want to keep track of which windows are yours, the best and
>>surest way to do it is...keep track of your windows!

>Or, use the windowKind field to identify it as (a) an application
>window, and hopefully (b) your window.  I quote from IM 1, p 276:

>>WindowKind identifies the window class.  If negative, it means the
>>window is a system window. [...] It may also be one of the following
>>predefined constants:
>>
>>    CONST dialogKind    = 2;     {dialog or alert window}
>>    CONST userKind      = 8;    {window created directly by the application}
>>
>>[...] UserKind represents a window created directly by application
>>calls to the Window Manager; for such windows the application can in
>>fact set the window class to any value greater than 8 if desired.
>                              ^^^^^^^^^^^^^^^^^^^^^^^^
>And that's the key.  You can pick some [hopefully unique] 16-bit value
>greater than 8 and, if you find a window with this value in its
>windowKind field, AND its refCon is a handle to data of the correct
>size, then chances are really really good that it's one of yours.

>Actually, unless you are writing an INIT or something, [i.e. if you
>are writing a normal application] any window with a windowKind >= 8
>MUST be one of your windows, so you can dispense with the check for a
>handle to a valid size.  You just have to be careful that ALL CREATED
>WINDOWS have a refCon that is either zero [NULL] or a valid handle.

Using the windowKind field of the WindowRecord to identify your windows
looks like a much better method than doing a GetHandleSize on the refCon,
for sure.  In normal applications, I simply set all my windows' windowKind
to 8 (userKind) and that never caused any problems.
There are some subtle problems, however, with the userKind field:

1.  If you develop using a THINK environment (I use THINK Pascal), you
    must keep in mind that your application's windowList also contains
    the development environment's windows.  So you may occasionaly get
    update/activate events for windows that aren't really yours.
    As for THINK Pascal, all THINK Pascal windows have a windowKind >=
    1000 (if I remember well; people at Symantec may confirm or deny),
    so it's a good idea to use a windowKind below 1000, at least when
    you run your application in the THINK environment.

2.  It appears that some Dialog Manager routines, notably DialogSelect,
    behave correctly only when your window has a windowKind of 2 (dialogKind).
    If you find useful to call DialogSelect on one of your application's
    windows (typically a modeless dialog), you should bracket the call
    with assignments to windowKind.

+------------------------------------------------------------+
|  EATING TOO MUCH IS CRIMINAL  -  Jenny Holzer "Truisms"    |
+------------------------------------------------------------+

---------------------------

End of C.S.M.P. Digest
**********************